A UART has a data connector connecting a transmitter to a receiver. The data sent from the transmitter to the receiver may be packet data. A packet is made up of multiple bytes of data. When the transmitter is sending packets asynchronously to the receiver it is important for the receiver to know where one packet ends and the next packet begins.
It is known for the receiver to count received bits/bytes from the start of communication. The first data bytes the receiver receives then must be the start of a packet. The receiver knows length information about the packet, and from this information the receiver can calculate when the end of the packet is received. Consequently, the next bytes it receives must be the start of the next packet. Thus the transmitter and receiver remain synchronised at the packet level.
Now, if an unknown number of bytes is lost because they don't fit in the receive buffer any more (“buffer overflow”) the receiver loses packet synchronisation, i.e. the knowledge about when the next packet begins. In order to prevent buffer overflow in the receiver a flow control mechanism is needed.
A UART has a data connector connecting a Transmitter to a Receiver and a control connector connecting the transmitter and receiver. Data in bit serial format is transported from the transmitter to the receiver via the data connector. The control connector carries a control signal RTS/CTS which implements flow control from receiver to transmitter by indicating “flow on” (RTS/CTS active) or “flow off” (RTS/CTS inactive). Flow control prevents too much data being sent by the transmitter and causing overflow of the receiver buffer memory.
There is an instance in the transmitter that controls transmission and should stop transmission after the last bit of the current byte if ‘flow off’ is indicated. This gives such strict timing requirements, that only a hardware instance can control RTS/CTS fast enough. The hardware can react immediately to the RTS/CTS signal (internal delays are only a fraction of the length of a single bit). If this instance is handled by a microprocessor (software flow control) which at some time, i.e. with some delay, discovers that the RTS/CTS is set to ‘flow off’ and then has to stop the UART from continuing transmission the delay may be in the range of multiple bytes, and in the worst case the exact delay is not predictable.
For hardware controlled RTS/CTS, when RTS/CTS is active, the transmitter sends data as a continuous data stream. It continuously sends data (byte after byte) while RTS/CTS remains active. When RTS/CTS goes inactive indicating “flow off”, the transmitter stops sending data. However, the transmitter does not stop sending data immediately, it continues to transmit until the end of the current byte. The receive buffer in the receiver is byte wise implemented. The receiver sets RTS/CTS inactive at a certain buffer level. Usually when the last byte is being written. It is, however, possible for the Transmitter to negotiate a longer time in order to react to a ‘flow off’ indication. (E.g. the H3 RS232 protocol in the Bluetooth specification VI.OB, 29 Nov. 1999). Here the transmitter tells the receiver that it has a latency of e.g. 100 μs. The receiver now has to set ‘flow off’ so early that it can still receive and store the amount of data that the transmitter will send during the next 100 μs. Therefore, it may set the ‘flow off’ indication RTS/CTS inactive when there is space in the receive buffer remaining for only a certain number of bytes e.g. 10 bytes.
Hardware flow control allows 100% prevention of a buffer overflow by signalling “flow off” within a predefined time. In this way packets aren't lost. A difficult situation arises when there is no hardware support for flow control. Bytes can get lost if the software in the receiver and the transmitter does not react fast enough to prevent buffer overflow. In this case packet synchronisation on the interface is lost.
To overcome the problem of loss of synchronisation when software flow control is used, a “packet delimiting” mechanism has been used. Packets are preceded/followed by a certain pattern as a packet delimiter. However, there are certain problems because the same delimiting pattern may occur within the packet that shall be transmitted. This problem has been solved for example, by the SLIP software protocol in which any occurrence of the delimiter in the data stream have to be replaced by “Escape sequences”. However, the software implementation of such a protocol is computationally intensive.
Therefore when there is no hardware support for flow control, bytes can get lost if the software does not react fast enough to prevent buffer overflow and either a complex and computationally intensive software protocol is used to delimit the packets or packet synchronisation on the interface is lost.
It would be desirable to provide an alternative flow control mechanism which provides packet synchronisation.
It would be desirable to provide the mechanism in software with a very low processing cost.
It would be desirable to provide the mechanism without altering the content or size of the packets.